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Spec if 1 crt 1 on of the Unified User-Level Protocol 


After mrny discussions of my RFC 451? I discovered thrt the "Unified 
User-Level Protocol" proposed therein hrd evolved into whrt hrd rlwrys 

BEEN ITS UNDERLYING MOTIVATION) R COMMON CDMNRND LANGUAGE . THERE RRE 
SEVERAL REASONS WHY THIS LATTER APPROACH SATISFIES THE ORIGINAL GOALS OF 
THE IJULP AND GOES BEYOND THEM INTO EVEN MORE USEFUL AREAS! 

1. User convenience. As evidenced by the good response to the common 

EDITOR "NETED"? THE NETWORK WORKING bRDUP HAS COME TO ACKNOWLEDGE THE 
FACT THAT THE CONVENIENCE OF NON - SYSTEM PROGRAMMER USERS OF THE NETWORK 

MUST BE SERVED. ALLOWING USERS TO INVOKE THE SAME GENERIC FUNCTIONS - 

INCLUDING "batch" JOES - IRRESPECTIVE OF WHICH SERVER HqST THEY HAPPEN 

TO BE USING IS SURELY A COMPELLING INITIAL JUSTIFICATION FOR A COMMON 
COMMAND LANGUAGE. NOTE THAT THE CONCERN WITH GENERIC FUNCTIONS - WHICH 

"all" Servers do? one way or another — is intended to emphasize the 1 

COMMON COMMAND SUBSET ASPECTS OF THE LANGUAGE ? RATHER THAN THE 

"linguistic" elegance of it all. The attempt is to specify an easy way 
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"everything" done. 

2. "Resource sharing". Another area which is receiving attention in the 

NWG OF LATE IS THAT OF "AUTOMATIC" OR PROGRAM-DRIVEN INVOCATION OF 
RESOURCES ON FOREIGN SYSTEMS. A COMMON INTERMEDIATE REPRESENTATION OF 
SOME SORT IS CLEARLY NECESSARY TO PERFORM SUCH FUNCTIONS IF WE ARE TO 
AVOID THE OLD "N BY M PROBLEM" OF THE TELNET PROTOCOL IN THIS CASE? N 

Hosts would otherwise have to keep track of m command languages. For the 

COMMON INTERMEDIATE REPRESENTATION TO BE HUMAN-USABLE SEEMS TO KILL TWO 
BIRDS WITH ONE STONE? AS EXPANDED UPON IN THE NEXT FOINT. 

3. Economy of mechanism. In RFC 451? I advanced the claim that a single 

USER-LEVEL PROTOCOL WHICH CONNECTED VIA SOCKET 1 AND TELNET WOULD OFFER 
ECONOMY OF MECHANISM IN THAT NEW RESPONDERS WOULD NOT BE REQUIRED TO 

service Initial Connection Protocols on socket after socket as protocol 

AFTER PROTOCOL EVOLVED. THIS CONSIDERATION STILL APPLIES? BUT AN EVEN 
GREATER ECONOMY IS VISIBLE WHEN WE CONSIDER THE CONTEXT OF RESOURCE 
SHARING. FOR IF THE COMMON COMMAND LANGUAGE IS DESIGNED FOR DIRECT 
EMPLOYMENT BY USERS? AS THE PRESENT PROPOSAL IS? THERE IS NO NEED FOR 
USERS ON TERMINAL SUPPORT "MINI-HOSTS" <E.G.? RUTS AND T IPs> TO REEUIRE 
AN INTERMEDIARY SERVER WHEN ALL THEY ACTUALLY WANT IS TO WORK ON A 

particular Server in the common language. (This is especially true in 

LIGHT OF THE FACT THAT MANY SUCH USERS ARE NOT PROFESSIONAL PROGRAMMERS 

- AND ARE FAMILIAR WITH NO COMMAND LANGUAGE.) THAT IS? IF RESOURCE 

SHARING IS ACHIEVED BY AN INTERMEDIATE LANGUAGE WHICH IS ONLY SUITABLE 
FOR PROGRAMS? YOU WOULD HAVE TO LEARN THE NATIVE COMMAND LANGUAGE OF 

Server B if you didn't want to incur the expense of using Server fl only 

TO GET AT GENERIC FUNCTIONS ON SERVER B. £ fl N D YOU MIGHT STILL HAVE TO 
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LEARN THE NATIVE LfiNuUflGE OF SERVER fit EVEN. IF THE EXPENSE OF USING TWO 

Servers where one would do isn' t a factor .) 

4. Front-ending. Another benefit of the common command language proposed 

HERE IS THAT IT IS EY AND LARGE INTENDED TO LEND ITSELF TO 
IMPLEMENTATION BY FRONT-ENDING ONTO EXISTING COMMANDS. THUS t THE 
UNPLEASANT NECESSITY OF THROWING OUT EXISTING IMPLEMENTATIONS IS 

minimized. Indeed; the approach taken is a conscious effort to come up 

WITH R COMMON COMMRND LRNGURGE BY ADDITION TO "NATIVE" COMMAND LANGUAGES 
RATHER THAN BY REPLACEMENT t FOR THE COMPELLING REASON THAT IT WOULD BE 
UNWORKABLE AS WELL AS ILL-ADVISED TO ATTEMPT To LEGISLATE THE RICHNESS 
REPRESENTED BY EXISTING COMMAND LANGUAGES OUT OF EXISTENCE. FURTHER) AS 
IT IS A CLOSED ENVIRONMENT) NO NAMING CONFLICTS WITH NATIVE COMMANDS 
WOULD ARISE. 

5. Accounting and authentication. As evidenced by the spate of P.FCs 

ABOUT THE IMPLICATIONS OF THE FTP IN REGARD TO BOTH ACCOUNTING FOR USE 

□ f Network services and authenticating users'’ identifications 
(Bressler's RFC 487 t F'ogran' s RFC 501, hnd my RFC 505 — and even 491), 

THIS AREA IS STILL UP IN THE AIR. THE GENERIC LOGIN COMMAND PROPOSED 
HERE SHOULD HELP MATTERS, AS IT ALLOWS THE SERVER TO ASSOCIATE AN 
APPROPRIATE PROCESS WITH THE CONNECTION WHILE ACTUATING APPROPRIATE . 
ACCOUNTING AND ACCESS CONTROL AS WELL, IF IT CHOOSES. 

6. Process-process functions. By enabling the invocation of foreign 

OBJECT PROGRAMS, THE PRESENT PROPOSAL OFFERS A RUBRIC IN WHICH SUCH 
PROCESS-TO-PROCESS FUNCTIONS AS "PARALLELISM" CAN BE PERFORMED. OiEE THE 
DISCUSSION OF THE "CALL" COMMAND, BELOW.) NOTE THAT THE IJULP IS NOT 
BEING ADVANCED AS A PANACEA • It IS ASSUMED THAT THE ACTUAL TRANSACTIONS 
CARRIED OUT ARE MOST LIKELY NOT GOING TO BE IN THE COMMON COMMAND 
LANGUAGE (ALTHOUGH SOME CERTAINLY COULD BE)5 HOWEVER, WHAT IS FURNISHED 
IS A KNOWN WAY OF GETTING THE PRESUMABLY SPECIAL-CASED PROGRAMS 
EXECUTING ELSEWHERE. RLSO, IT OFFERS A CONVENIENT ENVIRONMENT INTO WHICH 
CAN BE PLACED SUCH NEW FUNCTIONS, WHICH WE WOULD LIKE TO HAVE BECOME 
GENERIC, AS DAY'S FlLE RcCESS PROTOCOL. 

Rll of which seems to be a fair amount of mileage to get out of a 

DISTASTE FOR REMEMBERING WHETHER YOU FIND OUT WHO'S LOGGED IN BY SAYING 

"systat", "users", "s.who:c", "listf tty", or "who”.... 

Context 

Although ultimately intended to become the general responder to the 
Initial Connection Protocol, the UULP is initially to be a Telnet 
Protocol “negotiated option". When the option is enabled, the Server 
Host will furnish a command environment which supports the common 

CONVENTIONS AND COMMANDS DISCUSSED HEREIN. 

In a sense, the UULP is a "selector". That is, the common command subset 

INCLUDES COMMANDS TO EXIT FROM THE COMMON COMMAND ENVIRONMENT AND ENTER 
VARIOUS OTHER ENVIRONMENTS, ALONG THE LINES OF CCh'S CURRENT TELNET 

Server. To exit from the UULP environment to the "native; 1 command 

PROCESSOR , THE UULP COMMAND IS "LOCAL" (SEE ALSO THE DISCUSSION OF CASE , 

below) . Note that all commands terminate in Telnet "Newline" (currently 
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CR"LF) ? UNLESS FILTERED BY THE "eDL" COMMAND (lELDW) ! INTERNFtL SEPARATOR 

IS SPACE (BLANK) . ^ENTRANCE INTO OTHER ENVIRONMENTS-SUCH FiS THE FTP 

SERVER - IS DISCUSSED BELOW.) THERE ARE TWO REASONS FOR INTRODUCING ft 

MECHftN ISM OTHER THAN THE FlPPftRENTLY NATURAL ONE OF SIMPLY DE-NEGOTI AT ING 

the option: First? it is bound to be more convenient for the user to 

TYPE ft COMMAND THAN TO ESCAPE TO HIS USER TELNET PROGRAM TO CAUSE THE 
OPTION DISABLING. SECOND? IT IS HOPED THAT EVENTUALLY THE UULP WILL BE 
LEGISLATED TO BE THE DEFAULT ENVIRONMENT ENCOUNTERED BY ANY NETWORK 
LOGIN? IN WHICH CASE THE NATURAL WAY TO ENTER THE SERVER'S "NATIVE** 
COMMAND ENVIRONMENT WOULD BE BY UULP COMMAND. 

Note: all UULP commands discussed herein are listed in Appendix 1? 

CATEGORIZED AS TO OPTIONALITY ? WITH BRIEF DESCRIPTIONS GIVEN. The 
APPENDIX MAY BE TAKEN AS A FIRST-PASS UULP USERS' MANUAL. 

Responses 

Any optional commands which are not supported by a particular Server are 

TO BE RESPONDED TO BY A MESSAGE OF THE FORM "NOT IMPLEMENTED: 

COMMANDNAME . " ? WHERE THE VARIABLE IS THE NAME OF THE COMMAND WHICH WAS 
REGUESTED . MOTE THAT THROUGHOUT THIS DOCUMENT? ALL LITERALS MUST BE SENT 
EXACTLY AS SPECIFIED? SO AS TO ALLOW FOR THE POSSIBILITY OF SERVERS'* 
BEING DRIVEN BY PROGRAMS ''INCLUDING "AUTOMATA" OR "COMMAND MACROS" ) IN 
ADDITION TO "LIVE" USERS. 

In general? THE view has BEEN TAKEN HERE THAT A =;MALL NUMBER of literal? 
CONSTRAINED RESPONSES IS SUPERIOR TO A VAST VARIETY OF NUMERICALLY CODED 
RESPONSES IN WHICH TEXT MAY VARY. FlGAIN? THE MOTIVATION IS TO ACHIEVE AN 
ECONOMY OF MECHANISM. FOR ON THE CODED MODEL? THERE MUST BE A 

COORDINATOR OF CODE ASSIGNMENTS? WHICH IS JUST AS WELL AVOIDED. FURTHER?. 
AS HAS BEEN EXPERIENCED IN THE USE OF THE FTP? WHEN THERE ARE MANY CODES 
THERE ARE MANY AMBIGUITIES. (THE SENDER MAY HAVE A PERFECTLY VALID CASE 
FOR CHOOSING? SAY? 452? WHILE THE RECEIVER MAY HAVE AN EQUALLY GOOD 
INTERPRETATION OF THE CODES'* DEFINITIONS FOR EXPECTING? SAY? 453.) 
Experience with a related "error table" mechanism on Multics also bears 

OUT THE ASSERTION THAT CODED RESPONSES CREATE BOTH MANAGERIAL AND 
TECHNICAL PROBLEMS, fl FINAL OBJECTION TO NUMERIC CODES MIGHT BE 
CONSIDERED IREELEVANT BY SOME? BUT I THINK THAT THE AESTHETICS OF THE 
SITUATION DO MERIT SOME ATTENTION. HND WHEN THE COMMON COMMAND LANGUAGE 
IS BEING EMPLOYED BY LIVE USERS? IT SEEMS TO ME THAT THEY WOULD ONLY BE 
DISTRACTED BY ALL THOSE NUMBERS FLYING AROUND. ChOR CAN WE ASSUME THAT 
THE NUMBERS COULD BE STRIPPED BY THEIR "USER UULP" ? FOR ONE OF THE BASIC 
GOALS HERE IS TO MAKE IT STRAIGHTFORWARD ENOUGH FOR A USER AT A TIP TO 
DEAL WITH.) 

Arguments 

During the review process? it became evident that some global comments 

ON ARGUMENTS WERE IN ORDER. TWO AREAS IN PARTICULAR APPEAR TO HAVE LED 
TO SOME CONFUSION: THE STRATEGY OF SPECIFICATION OF ARGUMENTS ON THE . 
COMMANND LINE? AND THE GUEST I ON OF "CONTROL ARGUMENTS**. Dn THE FIRST 
SCORE? THE GOAL OF "FRONT - ENDftBILITY" MUST BE RECALLED. CONSIDER TWO 
NATIVE IMPLEMENTATIONS OF A PARTICULAR COMMAND? ONE OF WHICH Cfi) EXPECTS 
TO COLLECT ITS ARGUMENTS BY INTERROGATION OF THE USER? AND THE OTHER OF 
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WHICH (B) EXPECTS TO RECEIVE THEM ON INVOCATION ( EE IN'S INVOKED AS A 
CLOSED SUBROUTINE). NOW ? IT IS EASY TO IMAGINE THAT A "SERVER IJULP“ 
COULD FEED THE ARGUMENTS TO A AS NEEDED WITHOUT REQUIRING fl TO BE 
REWRITTEN? BUT IT IS QUITE DIFFICULT TO SEE HOW B COULD BE MADE TO 
INTERROGATE FOR ARGUMENTS WITHOUT EXTENSIVE REWRITING. THEREFORE? A 
'LEAST COMMON DENOMINATOR" APPROACH OF SPECIFYING ARGUMENTS IN ADVANCE 
INCURS THE MINIMUM COST IN TERMS OF REWORKING EXISTING IMPLEMENTATIONS. 

□ N THE SECOND SCORE? I HAVE BORROWED A NOTION FROM THE MlJLTICS COMMAND 
LANGUAGE'S CONVENTION CALLED "CONTROL ARGUMENTS" BECAUSE IT SEEMS TO BE 
QUITE CONVENIENT IN ACTUAL PRACTICE. THE KEY IS THAT SOME ARGUMENTS ARE 
MEANT AS LITERALS? USUALLY SPECIFYING A MODE OR CONTROL FUNCTION TO THE 
COMMAND? WHILE OTHERS ARE VARIABLES? SPECIFYING SOMETHING LIKE A 
PARTICULAR FILE NAME OR USER IDENTIFIER. A COMMON EXAMPLE IS A "MAIL" 
COMMAND? WHERE THE VARIABLES ARE THE USER IDENTIFIERS AND THE HOST 
IDENTIFIERS? AND THE "CONTROL ARGUMENT" IS THE DESIGNATOR THAT USER 
IDENTIFIERS HAVE CEASED AND HOST IDENTIFIERS HAVE BEGUN. THE CONVENTION 
USED HERE IS TO BEGIN THE CONTROL ARGUMENT WITH A HYPHEN? AS THIS 
CHARACTER NEVER SEEMS TO BE USED TO BEGIN VARIABLE ARGUMENTS. THUS? WE 

use "-at” in the mail example. Although it is not a deep philosophicai. 

POINT? THIS APPROACH DOES RELIEVE ARGUMENT LISTS OF ORDER-DEPENDENCY? 
AND FEELS RIGHT TO ME. 

Case 

Although it appears to have been legislated oui of existence by ihe 

SPECIFICATION OF THE NETWORK VIRTUAL TERMINAL'S KEYBOARD IN THE TELNET' 

Protocol? the question of what to do about users at upper-case-only 

TERMINALS REMAINS A THORNY ONE IN PRACTICE. THERE ARE TWO ASPECTS TO 
CONSIDER: THE ALPHABETIC CASE OF COMMANDS? AND THE ABILITY TO CAUSE 

"case-mapping" in order to allow lower-case input. Some Servers have no 

LOCAL PROBLEMS WITH THE FIRST ASPECT? AS THEY OPERATE INTERNALLY IN ALL 
UPPER-CASE OR ALL LOWER-CASE AND MERELY MAP ALL INPUT APPROPRIATELY. 

(Problems do arise? though? when one is using the User FTP on such a 

SYSTEM TO DEAL WITH A MIXED-CASE SYTEM ? FOR EXAMPLE.) OTHER SERVERS ? 
HOWEVER? ATTACH THE NORMAL LINGUISTIC SIGNIFICANCE TO CASE. (E.G.? 

Smith's name is "Smith" — not "SMITH"? and not "smith”.) To minimize 

SUPERFLUOUS PROCESSING FOR THOSE SERVERS WHICH ARE INDIFFERENT TO CASE? 
ALL UULP COMMANDS ARE TO BE RECOGNIZED AS SUCH WHETHER THEY ARRIVE AS 
ALL UPPER-CASE OR ALL LOWER-CASE. (THEY WILL BE SHOWN HERE AS ALL LOWER 
MERELY FOR TYPING CONVENIENCE.) NOTE THAT ARBITRARILY MIXED CASE IS NOT 
RECOGNIZED? AS IT IS AN UNWARRANTED ASSUMPTION ABOUT LOCAL 
IMPLEMENTATION TO SUPPOSE THAT INPUT WILL NECESSARILY BE CASE-MAPPED. 

□n the second aspect? any Server which does distinguish between upper- 

AND LOWER-CASE IN COMMANDS'' ARGUMENTS (A.K.A. PARAMETERS) MUST FURNISH A 

UULP "map" command as specified in Rppendix 2 IN order to support logins 

FROM UPPER-CASE-ONLY TERMINALS ATTACHED TO USER HOSTS WHICH EITHER DO 
NOT SUPPORT THE TELNET PROTOCOL'S DICTUM THAT ALL 128 ASCII CODES MUST 
BE GENERABLE? OR SUPPORT IT AWKWARDLY. THIS SEEMS A SIMPLER AND 
PREFERABLE SOLUTION THAN THE ALTERNATIVE OF LEGISLATING THAT UPPER-CASE 

Met work—wide personal identifiers (and perhaps even Network Virt'-'al Path 
Names) ee pre-conditions to a usable common command subset. (As noted 

BELOW? THESE LATTER CONCEPTS WILL FIT IN SMOOTHLY WHEN THEY ARE AGREED 
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upon. The point here* though? is that 
THE BENEFITS OF A UULP UNTIL THEY RRE 


WE NEED NOT 
AGREED UPON 


DEPRIVE 

> 


OURSELVES 


OF 


User Names 

i 

fls IMPLIED ABOVE? THE VARIOUS SERVERS HAVE THEIR VRRIOUS WRYS OF 
EXPRESSING USERS'' NRMES. CLEARLY J THE PRINCIPLE OF ECONOMY OF MEMORY 
DICTATES THAT THERE SHOULD BE R COMMON INTERMEDIATE REPRESENTATION OF 
NRMES IN AND FOR THE NETWORK. It IS PROBABLY ALSO CLEAR THAT THIS 
REPRESENTATION WILL BE BASED UPON THE NETWORK INFORMATION CENTER / S "NIC 
ID's". However? it is unfortunately amply clear than an acceptable 

MECHANISM FOR SECURING UP-TO-DATE INFORMATION CANNOT EE LEGISLATED HERE 
- MUCHLESS A MECHANISM FOR SECURELY UPDATING THE IMPLIED DATA BASE. 

Therefore? at this stage it seems to be the sensible thing to specify 
ONLY THE UULP SYNTAX FOR CONVEYING TO THE SERVER THE FACT THAT IT IS TO 
TREAT A USER NAME AS A NeTWORK“WIDE NAME RATHER THAN AS A LOCAL NAME ? 
AND LET THE SUPPORTING MECHANISMS EVOLVE AS THEY MAY. 


The prefacing of a name with an asterisk <“♦") denotes a Network-wide 
name. (Such names may be either all upper-case or all lower-case? as 
with UULP commands' names.) The name "♦free" is explicitly reserved to 

MEAN THAT ( IN THE CONTEXT OF LOGGING IN) A LOGIN IS DESIRED ON A 
SUPPORTED OR SAMPLING ACCOUNT? IF SUCH AN ACCOUNT IS AVAILABLE. THE 
RESPONSE IF NO SUCH ACCOUNT IS AVAILABLE IS TO BE "INVALID IDENTS 

♦free." When Network-wide names are generally available Servers will 

EITHER map them INTO LPCAI NAMES OR CAUSE THEM TO BE REGISTERED AS LOCAL 
NAMES AS THEY PREFER. THE POINT IS THAT A NeTWORK~WIDE NAME WILL BE 

"made to work" by the Server in the context of the UULP. 


Special Characters and Signals 


Another area in which the facts of life must outweigh the letter of the 
Telnet Protocol if the user's convenience is to be served is tha.t of 
"erase" and "kill" characters. It is possible that User Telnets will 

UNIFORMLY FACILITATE THE TRANSMISSION OF THE TELNET CONTROL CODES FOR 
GENERIC CHARACTER ERASE AND GENERIC LINE KILL. IT IS CERTAIN? HOWEVER? 

that User Telnets will differ — and users will? if they use more than 
one User Telnet? be again placed in the uncomfortable position of having 
TO DEVELOP TOO MANY SETS OF REFLEXES. THEREFORE? THE UULP WILL 
OPTIONALLY SUPPORT THE FOLLOWING COMMANDS I "ERASE CHAR" AND "KILL CHAR" ? 
WHERE CHAR IS A PRINTABLE ASCII CHARACTER (TO AVOID POSSIBLE CONFLICTS 
WITH "CONTROL CHARACTERS" WHICH ARE RECOGNIZED IN THE INNERMOST AREAS OF 
PARTICULAR OPERATING SYSTEMS). PRESUMABLY? UNWARY USERS CAN BE 
INSTRUCTED NOT TO CHOOSE AN ALPHABETIC? SO AS TO AVOID BEING PLACED IN A 
POSITION WHERE THEY CANNOT INVOKE CERTAIN COMMANDS (ERASE AND KILL 
THEMSELVES? FOR EXAMPLE? IN WHICH CASE THEY COULDN'T BE CHANGED). 

These commands are supplements to the related Telnet control codes? and 

HAVE THE SAME MEANINGS. THE POINT HERE IS THAT IT MAY BE FAR MORE 
CONVENIENT FOR A USER TO BE ABLE TO SAY "ERASE «" AND GET THE "““ TO BE 
RECOGNIZED AS THE ERASE CHARACTER BY THE SERVER THAN FOR THE, USER TO GET 

his User Telnet to send the Telnet equivalent. The commands 1 are 

DESIGNATED AS OPTIONAL BECAUSE THEY MAY LEAD TO SEVERE IMPLEMENTATION 



Unified User-Level Protocol C63 


/ 


PROBLEMS ON SOME i-ERVERS ) AND BECAUSE THE EtPU IVALENT FUNCTIONS DO ) AFTER 
ALL) EXIST IN TELNET. 

Note: the erasing is assumed to be performed "as early as possible". 

THAT IS) THE SEBUENCE "ERASE X" “ERASE X" SHOULD COME OUT EGUIVALENT 

TO "ERASE x" "ERASE"-THE SECOND APPEARANCE OF " X" RESULT IN'S IN THE 

ERASING OF THE SPACE IN THE COMMAND LINE. PRESUMABLY) THIS IS A 
SUFFICIENTLY UNCOMMON PATH THAT ANOMALOUS RESULTS WOULD EE TOLERATED 
BY THE USER COMMUNITY > BUT THE INTENT OUGHT TO BE CLEAR. 

The Telnet "synch" and "ereak" mechanisms are» by their very nature » 

BEST LEFT TO TELNET. End OF LINE) HOWEVER) MIGHT WELL BE A DIFFERENT 
STORY. THEREFORE) AS A POTENTIAL CONVENIENCE) THE IJULP OPTIONALLY 
SUPPORTS "EOL CHAR" TO ASK THE SERVER TO TREAT CHAR AS THE END OF LINE 
CHARACTER THENCEFORTH. To REVERT TO TELNET NEWLINE) "EOL" <I.E.) NO 
ARGUMENT) CURRENT TERMINATOR). 


Prompts 

Another aspect■in which Servers vary while being the same is how they 

INDICATE "BEING AT COMMRND LEVEL". SOME OUTPUT "READY MESSAGES" ) OTHERS) 

"prompt chrrrcters" . For the IJULP) where some functions will be 

PERFORMED BY MERNS OF R COMMRND"S LOGGING IN TO RNOTHER SYSTEM) THE 
ABILITY TO SPECIFY R KNOWN PROMPT CHARACTER IS EXTREMELY DESIRRBLE. THE 
UULP COMMRND IS "PROMPT CHAR" WHERE CHRR IS THE CHRRRCTER WHICH IS TO BE 
SENT WMON THIS Uscn^S PROCESS C OH THE GERVER } IS RT COMMRND LEVEL. IT iS 
EXPLICITLY PERMITTED TO PREFIX CHRR TO R LINE CONSISTING OF R "NATIVE" 
FROMF'T OR RERDY MESSRGE . HLSO ) THIS COMMRND IS EXPLICITLY RCKN OWL EDGED 
TO BE PERMISSIBLE PRIOR TO LOGIN. CftGAIN) WRRNING MUST BE MRDE OF THE 
BRD RESULTS WHICH CRN ENSUE IF RN RLPHRBETIC CHRRRCTER IS CHOSEN.) 

Note: "prompt") "eol" ) "erase"> and "kill" mry rll be re-invoked with 

R NEW VALUE OF CHRR IN ORDER TO CHANGE THE RELEVANT SETTING) RLL MRY 
BE TURNED OFF BY INVOCATION WITH NO ARGUMENT. 

Login . / 

Perhaps the stickiest wicket of them all is the attempt to specify r 

GENERIC LOGIN) BUT HERE WE GO. ThE UULP LOGIN COMMRND IS "LOGIN 
USERIDENT" ) WHERE USER I DENT IS EITHER R LOCALLY - ACCEPTABLE USER 
IDENTIFIER OR R NETWORK-WIDE IDENTIFIER RS DISCUSSED ABOVE. NOTE THRT 
FOR UTILITY IN CONTEXTS TO EE DISCUSSED LATER) THE LOCALLY - ACCEPT ABLE 
FORM MUST NOT CONTAIN SPACES. SERVERS MRY RESPOND TO THE LOGIN ATTEMPT 
WITH ARBITRARY TEXT (SUCH RS R “MESSAGE OF THE DAY")) BUT SOME LINE OF 
THE RESPONSE MUST EE ONE OF THE FOLLOWING: R FROMPT (AS DISCUSSED ABOVE) 
INDICATING) IN THE PRESENT CONTEXT) SUCCESSFUL LOGIN)') "PASSWORD:") OR 

"Invalid ident: userident." When passwords are required) it is the 
Server^ responsibility either to send a mask or to successfully 

NEGOTIATE THE HlDE YOUR INPUT OPTION. 

Note that "login ♦free" is specifically defined to reeuire.;no password. 
<If a "freeloader” has access to a User Telnet and has learned of the 

“♦free" SYNTAX) IT IS FRUITLESS TO ASSUME THAT HE COULDN'T HAVE ALSO 
READ THE COMMON PASSWORD.) IF A PASSWORD MUST BE GIVEN) ACCEPTABLE 
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RESPONSES RRE RRBITRfiRY TEXT CONTAINING A LINE BEGINNING EITHER WITH A 
PROMPT DR WITH "LOGIN UNSUCCESSFUL . " OR WITH "ACCOUNT !“. If AN ACCOUNT 
IS REQUESTED ? THE RESPONSES MUST EE EITHER THE "LOGIN UNSUCCESSFUL." 
MESSAGE OR THE TEXT CONTAINING A PROMPT ALREADY DESCRIBED. If ANY ERRORS 
OCCUR DURING THE LOGIN SEQUENCE ? USERS ARE TO RE—TRY BY STARTING FROM 
THE LOGIN COMMAND. (I .E . ? IT IS NOT REQUIRED THAT THE SERVER "REMEMBER” 
IDENTS OR PASSWORDS.) 

It IS EXPLICITLY ACKNOWLEDGED THAT AN ACCEPTABLE RESPONSE TO “LOGIN 

♦free" is "Limited access only." (followed by a prompt). This is 

INTENDED TO WARN (HUMAN) USERS THAT THE FREE ACCOUNT ON THE SERVER IN' 
QUESTION EXISTS ONLY TO ALLOW SUCH FUNCTIONS AS ACCEPTING MAIL AND 
TELLING IF A PARTICULAR USER HAPPENS TO BE LOGGED IN. (FOR OBJECTIONS TO 

"loginless" performance of such tasks ? see RFC 491. Mote also that 

NOTHING HERE SAYS THAT A SERVER MUST DO ANYTHING OTHER THAN RETURN A 
PROMPT IN RESPONSE TO "LOGIN ♦FREE" IN THE EVENT THhT LOGINLESS 
OPERATION IS NATURAL TO IT.) blVEN THE IJULP LOGIN DISCIPLINE AND THE 
"PROMPT" COMMAND.' IT IS REASONABLY STRAIGHTFORWARD FOR A PROGRAM TO 
LOGIN ON A FREE ACCOUNT AND PERFORM ONE OF THESE FUNCTIONS ? FOR IF THE 
LOGIN COMMAND SUCCEEDED? THE PROGRAM WILL "SEE” A GUARANTEED PROMPT 
CHARACTER. 

To MAKE LIFE SIMPLER FOR THOSE HOSTS WHICH NORMALLY HAVE SOME SORT OF 
"DAEMON" PROCESS SERVICE MAIL AND THE LIKE? A FURTHER EXPANSION TO LOGIN 

is in order. The point here is that some Hosts may not know what sort of 

PROCESS TO PASS AN UNG3UALIFI ED "LOGIN ♦FREE" TO? WHEREAS THEY' D BE SURE 
WHAT TO DO WITH AN EXPLICIT REQUEST TO PROCESS MAIL? DO A WHO COMMAND? 

OR SET UP- CONSOLE TO CONSOLE COMMUNICATIONS. THEREFORE? UOLP “LOGIN" 

WILL ALLOW A "CONTROL ARGUMENT" (AS DISCUSSED ABOVE) OF EITHER "-MAIL"? 
"-who"? OR "-CONCOM"? AND THE RESPECTIVE UULP COMMANDS INVOLVED MUST USE 
THE RESPECTIVE STRINGS IN ANY LOGIN LINE THEY TRANSMIT. HGAIN? NOTHING 
IS BEING SAID ABOUT WHAT A SERVER HAS TO DO WITH THE INFORMATION? BUT 

some Servers needxwant it. 

Usage Information 

Most Servers offer some sort of on-line documentation? from calling 

SEQUENCES OF COMMANDS TO ENTIRE USERS'' MANUALS. THERE ARE TWO SORTS OF 
INFORMATION OF INTEREST IN THE UULP ENVIRONMENT! "NORMAL" SYSTEM 
INFORMATION? AND INFORMATION ABOUT THE PARTICULAR SERVER'S UULP 
IMPLEMENTATION. To LEARN HOW TO GET DESCRIPTIONS OF "NATIVE" COMMANDS? 
THE UULP COMMAND IS "HELP "SYS" (ABBREVIATION! "?“). MOTE THAT "“SYS" IS 
VIEWED AS A "CONTROL ARGUMENT" AND.AS SUCH PREFACED BY A HYPHEN ("-") TO 
FACILITATE DISTINCTION FROM OTHER SORTS OF NAME (e.G.? COMMAND NAMES). 

TO GET A DESCRIPTION OF THE SERVER'S UULP IMPLEMENTATION? "HELP -UULP". 
TO GET A DESCRIPTION OF A PARTICULAR UULP COMMAND'S IMPLEMENTATION? 

"HELP COMNAME". TO BE REMINDED OF HOW TO USE THE HELP COMMAND? "HELP". 

Note: as with command names and Network-wide user names? control 

AGRUMENTS MAY BE EITHER ALL UPPER-CASE OR ALL LOWER-CASE. 

IT IS SPECIFICALLY ACKNOWLEDGED THAT "ISO PECULIARITIES." IS AN 
APPROPRIATE RESPONSE TO "HELP COMNAME" IF NOTHING OF INTEREST NEED BE 
SAID ABOUT THE SERVER'S IMPLEMENTATION OF THE UULP COMMAND IN GUEST ION. 
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(After rlli we're sparing users the necessity qf studying r dozen dr sd 

USERS'' MANUALS ? THE LEAST THEY CRN DO IS TD RERD THE IJULP COMMAND LIST.) 
hPPROPRIATE INFORMATION FDR LESS TACITURN HOSTS TD FURNISH WOULD BE SUCH 
DRTR RS LOCAL COMMAND INVOKED (IF SUCH BE THE CASE)J ARGUMENT SYNTAX 
(E.G.? PATHNAME DESCRIPTION? DR NAME DF HELP FILE ABOUT PATHNAMES)? " To 

EE IMPLEMENTED."? DR EVEN "NOT TD BE IMPLEMENTED." 

"Mail" 

Even though r separate mril protocol is being evolved fdr general 

PURPOSES I THE UULP NEEDS TD RDDRESS THIS TOPIC RS?' BY VIRTUE DF BEING 
LOGIN ERSED? IT ALLDWS SYSTEMS WHICH DD ACCESS CONTROL RND SENDER 
AUTHENTICATION DN MRIL TD MAKE THESE ABILITIES AVAILABLE TD USERS WITHIN 
ITS FRRMEWDRK DF GENERIC FUNCTIONS. THEREFORE? TD RERD ONE'S MAILBOX? 

THE UULP COMMAND IS "READMAIL" . To HAVE "LIVE" INPUT COLLECTED RND SENT 
TD R LOCAL USER? "MAIL USERIDENT"? TO R REMOTE USER? "MAIL USERIDENT “AT 
HOSTNAME"? WHERE THE ARGUMENTS HAVE THE "aBVIOUS" MEANINGS. Td SEND ft 
PREVIOUSLY-CREATED FILE? "MAIL ~F FILENAME USERIDENT “AT HOSTNAME". 

Several useridents may be furnished? the delimiter is space (blank). 
Similar considerations apply to hostnames. If both are lists? they sould 

BE TREATED PAIRWISE, .(fl MORE ELABORATE SYNTAX COULD BE INVENTED TO DEAL 
WITH THE DESIRE TD SEND TO SEVERAL USERS AT A GIVEN HOST AND THEN TO 
OTHER USERS AT OTHER HOSTS? BUT IT SEEMS UNNECESSARY TO DD SO AT THIS 
POINT? FOR MULTIPLE INVOCATIONS WOULD GET THE JOB DONE.) 

The mail command prefaces the message wtth r line identifying the sender 
(Host rnd time desirable? but not mandatory). For “live” collection? the' 

END OF MESSAGE IS INDICATED BY R LINE CONSISTING OF ONLY R PERIOD ( “ . “ ) 
FOLLOWED BY THE REGNANT LINE TERMINATOR (USUALLY THE TELNET MeWLINE? BUT 
SEE ALSO THE DISCUSSION OF THE EOL COMMAND). IF REMOTE MAIL IS NOT 
SUCCESSFULLY TRANSMITTED? IT IS TO BE SAVED IN A LOCAL FILE AND THAT 
FILE'S NAME IS TO BE OUTFUT AS PART OF THE FAILURE MESSAGE. (“QUEUEING” 
FOR LATER TRANSMISSION IS ADMIRED? BUT NOT REQUIRED.) The TRANSMISSION 
MECHANISM WILL FOLLOW THE GENERAL MAIL PROTOCOL. hOTE THAT WHEN INVOKED 
WITH A "-AT" CLAUSE? THE MAIL COMMAND WILL SEND "LOGIN ♦FREE -MAIL" TO 
THE REMOTE HoST<S)? FOLLOWED BY A MAIL COMMAND WITH NO "-AT** CLAUSE. 

R DESIRABLE? BUT NOT REQUIRED? EMBELLISHMENT TO "READMAIL" WOULD BE THE 
ACCEPTING' OF A HOST NAME ("-AT HOSTNAME") TO CAUSE THE LOCAL HOST TO GO 
OFF TO THE NAMED HOST (VIA "LOGIN ♦FREE “MAIL") AND CHECK FDR MAIL 

there. Several hostnames could? of course? be specified, fi further 

EMBELLISHMENT? WHICH WOULD PROBABLY BE QUITE EXPENSIVE? WOULD BE TO 
ACCEPT “-ALL" AS A REQUEST TO CHECK ALL HOSTS (DR? PERHAPS? ALL HOSTS 
KNOWN TO HAVE A FREE ACCOUNT FOR THE PURPOSE) FOR MAIL. 

Direct Communication 

The ability to exchange messages directly with other logged in users is 

APPARENTLY GREATLY PRIZED BY MANY USERS. THEREFORE? DESPITE THE FACT 
THAT THERE IS A SENSE IN WHICH THIS FUNCTION IS NOT WITHIN THE PURVIEW 
□F THE UULP? WE WILL ADDRESS.IT? AFTER A DIGRESSION. 

Digression! The UULP assumes that there can be straightforward “front 
ends" at the various Servers which translate generic function calls 
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IN M COMMON SPELLING TD CRLUS FOR SPEC IFIC 9 ■ PRE-EX I ST ING ’NATIVE" 
FUNCTIONS. In THE RREfl OF CONSOLE TD CONSOLE COMMUNICRTIONSI HOWEVERf 
THIS PREMISE DDES NOT RERLLY HOLD. THE PROBLEM IS THAT BOTH MAJOR 
" NATIVE" IMPLEMENTATIONS KNOWN TO THE AUTHOR FiRE SERIOUSLY FLAWED. 

The TENEX "link" mechanism is both insecure {you've got no business 

SEEING EVERYTHING I TYPE EVEN IF I'M CARELESS ENOUGH TD LET YOU) AND 
INCONVENIENT {WHY SHOULD I EE FORCED TD REMEMBER THAT PESKY 
SEMI-COLON? HDW DO I GET BACK INTO PHASE AFTER I'VE FORGOTTEN ONE?) . 
IT IS ALSD LIKELY TD BE EXTREMELY DIFFICULT TD SIMULATE DN SYSTEMS 
WHICH DD NDT FORCE NETWORK I'D THROUGH LOCAL TTY BUFFERS ? EVEN IF THE 
USER INTERFACE WERE NDT SUBJECT TD CRITICISM. THE MULTICS 

"SENDFMESSAGE" MECHANISM- DN THE OTHER HAND? HRS R MDRE SOPHIST ICRTED 
DESIGN ? BUT IS ABSURDLY EXPENSIVE. THEREFORE? THE UULP MECHANISM TO 
EE DESCRIBED ASSUMES THAT ? FOR THIS FUNCTION? NEW LOCAL 
IMPLEMENTATIONS WILL BE DEVELOPED TO SUPPORT IT. 

TO PERMIT CONSOLE TO CONSOLE COMMUNICATIONS! “CONCOM “ON"? TO REFUSE ? 

"concom -off". Default is off. To enter message-sending mode: concom 

USER I DENT “AT HOSTNAME" {"“AT" CLAUSE IS OPTIONAL). TO EXIT FROM 
MESSAGE-SENDING MODE?. TYPE A LINE CONSISTING OF ONLY A PERIOD (CF. MAIL? 

above). While in message-sending mode? each line will be transmitted as 
a unit. The first message sent by concom must be prefaced by an 

IDENTIFYING LINE? BEGINNING "FROM 5 " FiND CONTAINING AN APPROPRIATE 
ADDRESS TO WHICH TO REPLY. THE CLOSING PERIOD-ONLY LINE SHOULD BE 
TRANSMITTED? SO AS TO ALLOW THE OTHER CONCOM TO CLOSE AS WELL. 

Acceptable error response is "Not available: userident." {which neither 

CONFIRMS NOR DENIES THE EXISTENCE OF THE PARTICULAR USER - A MATTER OF 

CONCERN ON THE SECURITY FRONT). THE COMMAND MUST? OF COURSE? DO WHATEVER 
IS NECESSARY TO TRANSMIT THE MESSAGES? I.E.? IF LOCALLY INVOKED? ACCESS 
THE LOCAL MECHANISM? AND IF INVOKED FOR REMOTE COMMUNICATIONS? ACCESS 
THE REMOTE HOST 'S CONCOM COMMAND {VIA "LOGIN ♦FREE "CONCOM") . T HUS ? A 
USER AT A TIP WOULD USE THE LOCAL FORM OF CONCOM ON THE HOST OF THE 
OTHER PARTY. IF THIS IS CONVENIENT? OR WOULD USE THE REMOTE FORM ON HIS 

"usual" Server if the direct use is inconvenient for some reason (such 

AS HAVING NO ACCOUNT THERE? SAY). 

The prerequisites for establishing communications are to find out if the 

USER IS LOGGED IN? AND WHAT "ADDRESS." TO USE IF SO. THE MECHANISM FOR 
GATHERING THIS INFORMATION IS AN EXPANDED "WHO" COMMAND. (NOTE THAT 
"WHO" IS THE UULP COMMAND TO INVOKE THE GENERIC WHO'S LOGGED IN 
FUNCTION? WITH NO CONSTRAINTS ON FORMAT OF REPLY.) THE SYNTAX IS “WHO 
USERIDENT -AT HOSTNAME"? WHERE BOTH ARGUMENTS MAY BE MULTIPLE. IF NO 

"-at" clause? then check local Host only. Response must begin "From 
hostname: userident:" followed by either an appropriate address (e.g.? 

"11" IF LOCAL "CONCOM" USES TTY NUMBERS AND USERIDENT IS LOGGED IN ON 

TTY ID? or "Hot available." 

Rs WITH MAIL? A "“ALL" EMBELLISHMENT MIGHT EE PLEASANT. MOTE THAT THE 

SEARCH FOR THE SPECIFIED USER(s) - WHETHER OR NOT "“ALL" IS USED - 

STILL ASSUMES THAT A "LOGIN ♦FREE “WHO" LOGIN WILL BE USED ON THE 
APPROPRIATE REMOTE HoST(s)? FOLLOWED BY "WHO USERIDENT". THIS IS WHY 
RESPONSES TO THE EXPANDED WHO COMMAND MUST BE SO RIGIDLY SPECIFIED. NOTE 
ALSO THAT REGARDLESS OF WHETHER THE INQUIRY IS MADE IN TERMS OF 
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Network— wi de or local user name) the response must be appropriate for 
use in "concom" . 

'’Good" concom implementations will presumably do an expanded who command 

AUTOMATICALLY ? SO AS TO SPARE THE USER THE NECESSITY OF HAVING TO DO IT 
SEPARATELY. INDEED? THE “CONCOM CONTROL ARGUMENT TO LOGIN IS DEFINED TO 
IMPLY THE ABILITY TO DO A WHO AS WELL AS A CONCOM TO CATER TO THIS 
POSSIBILITY . It IS TEMPTING TO LEGISLATE THAT SUCH AN APPROACH BE THE 
RULE? BUT THE IMPLEMENTATION IMPLICATIONS ARE NOT EUITE CLEAR ENOUGH TO 

do so. The implicit who should be viewed as a strong hint to 

IMPLEMENTERS? THOUGH. 

File Creation and Manipulation 

The common command subset must furnish the ability to create and 
manipulate files. Creation is necessary in order to send mail on the one 

HAND? AND TO PRODUCE SOURCE FILES FOR SUBSEQUENT COMPILATION ON THE 
OTHER HAND. MANIPULATION tSUCH AS COPYING? RENAMING? TYPING OUT? AND THE 
LIKE) IS NECESSARY BOTH AS A CONVENIENCE ASPECT FOR USERS WHO SEEK TO 
OPERATE ONLY IN THE COMMON COMMAND LANGUAGE AND AS A MEANS OF PERFORMING 
DESIRED BATCH FUNCTIONS < SEE BELOW). FOR FILE MANIPULATION COMMMANDS t 
THE USER COULD ENTER THE FlLE TRANSFER PROTOCOL ENVIRONMENT. HOWEVER? 

THE FTP USER INTERFACE IS CONSTRAINED BY A VERY HIGH DEGREE - OF 
PROGRAM - DRIVABILITY . It ALSO LACKS ABBREVIATIONS AND SUFFERS FROM THE 
LACK OF MNEMONICITY DICTATED BY LIMITING COMMAND NAMES TO FOUR 
CHARACTERS. FURTHER* SOME VALUABLE FUNCTIONS SUCH AS CAUSING A FILE TO 
BE TYPED OUT) ARE NOT DEALT WITH. THEREFORE? VARIOUS UULP FILE 
MANIPULATION COMMANDS ARE GIVEN IN APPENDIX 1. THEY NEED NOT BE j~ 

ADDRESSED IN DETAIL HERE. HOWEVER? SOME CONTEXT WOULD BE USEFUL! 

The file manipulation commands assume that all Servers have some notion 

ROUGHLY CORRESPONDING TO “THE USER'S WORKING DIRECTORY". RLL FILE NAMES? 
WHETHER THE YET TO BE INVENTED NETWORK VIRTUAL PATHNAME OR THE "LOCAL” 
VARIETY? ARE TAKEN TO REFER TO FILES IN THIS DIRECTORY UNLESS OTHERWISE 
INDICATED. That IS? THE USER SHOULD NOT HAVE TO FURNISH "DSKs" OR THE 
LIKE? IT IS TAKEN AS GIVEN THAT WHEN HE REFERS TO FILE "x" HE MEANS "THE 
FILE NAMED 'X ' IN MY CURRENT WORKING DIRECTORY" AND THE SERVER "KNDWS" 
WHAT THAT MEANS. 

HT THE PRESENT STAGE OF DEVELOPMENT OF THE UULP? IT DOES NOT SEEM 
FRUITFUL TO GO INTO A REASONED EXPLICATION OF THE FOLLOWING STATEMENT. 

For now? suffice it to say that those file manipulation commands <a copy 

OF A FOREIGN FILE? FOR EXAMPLE) WHICH NEED TO EMPLOY THE FTP DO EMPLOY 
THE FTP AND LET IT GO AT THAT. flS THE CONTEXT AND IMPLICATIONS OF THE 
FROTOCOL BECOME MORE WIDELY UNDERSTOOD? THE DETAILED IMPLEMENTATION 

NOTES WILL BE ADDED TO THE FILE COMMANDS - AND REFINED FOR THE OTHER 

COMMANDS? DOUBTLESS. In A WAY? THE COMMON FILE COMMANDS MAY BE VIEWED AS 

a kind of "User FTP" of known human interface when they deal with 

FOREIGN FILES. CPnD? OF COURSE? UNTIL THERE ^ S A NETWORK VIRTUAL 
PATHNAME? THE ISSUE DOESN'T REALLY ARISE.) I EXPECT THAT AN "IDENTIFY" 
COMMAND MIGHT BE DESIRABLE? 30 THAT UULP COMMANDS WHICH HAVE TO ACCESS 
other Servers in turn on behalf of the specific current user can have 

THE NECESSARY LOGIN INFORMATION AVAILABLE TO THEM. SUCH A COMMAND IS 
INCLUDED IN HPPENDIX 1? BUT SHOULD RANK AS SPECULATION FOR NOW. 
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□n THE TOPIC OF FILE CREATION) MATTERS ARE RATHER COMPLICATED. It IS 
CLEAR THAT THE ABILITY TO CREATE FILES IN THE UULP ENVIRONMENT IS 
EXTREMELY DESIRABLE. It IS ALSO CLEAR THAT USING MAIL TO A FAKE ADDRESS 
TO GET THE FILE CREATED) THEN RENAMING THE "UNSENT MAIL" FILE IS TOO 
BY2ANTINE TO EXPECT USERS TO DO. UNFORTUNATELY) IT IS NOT CLEAR EXACTLY 
WHAT THE ALTERNATIVE IS. THAT IS) IT'S FAIRLY CLEAR THAT WE NEED A 
COMMON EDITOR* BUT IT'S NOT RT RLL CLERR WHICH EDITOR IT SHOULD BE. 

TWO WIDELY-KNOWN EDITORS COME TO MIND! TECO RND QED . HOWEVER) NOT 
EVERYBODY HRS THEM. EVEN IF EVERYBODY DID* THE "DIRLECTS" PROBLEM IS 
BOUND TO BE R LRRGE ONE. EVEN IF RLL THE RELEVANT SYSTEM PROGRRMMERS 
COULD RGREEJ THERE REMRINS THE KUESTION OF WHETHER THE INTENDED USER 
POPULATION WOULD BE WILLING TO BOTHER LERRNING R LANGUAGE RS COMPLEX RS 

TECO or QED. Therefore rn optional UULP command to be crlled "neted“ is 
proposed. <See rlso RFC 569.) This editor is r line-oriented context 
editor (no "regular expressions"* but rlso no line numbers). It is 
COPIOUSLY DOCUMENTED IN CHRPTER 4 DR THE MlJLTICS PROGRAMMERS' MANUAL* 
INCLUDING RN RNNOTRTED LISTING OF THE (PLXl) SOURCE CODE, fl SIMPLE 
user's GUIDE HRS BEEN PREPARED (SEE ftPPENDIX 3). SEVERAL IMPLENTRTIONS 
ALRERDY EXIST* RND COMMITMENTS HRVE BEEN MRDE FOR MORE. It MRY RLSO BE 
REPUGNANT TO SOME OP THE SYSTEM PROGRRMMERS WHO WOULD BE CRLLED UPON TO 

IMPLEMENT IT WHICH IS WHY IT IS DPTIONRL* UNTIL RND UNLESS HIGHER 

RU THORITY MRKES IT MRNDRTORY. 

Other Protocols 

The nominrl initial impetus for proposing r UULP was to rllow new 
Network user protocols to be invokrble through r common mechanism* 

RATHER THAN REQUIRING R NEW RESPONDING MECHANISM TO BE BUILT FOR R NEW 
CONTACT SOCKET FOR EACH NEW PROTOCOL. ALTHOUGH THIS GORL HRS BEEN 
SHUNTED INTO THE BACKGROUND BY THE RDMISSION OF THE TRUE GORL OF THE 
UULP* IT HRS NOT BEEN DROPPED COMPLETELY. THEREFORE* TO ENTER THE FTP 

Server environment* the UULP commrnd is "ftp"* to enter the RJE Server 

ENVIRONMENT* THE UULP COMMRND IS "RJE“. EXIT IS RS PER THE RESPECTIVE 

protocols. (Where possible* exit should be back to the UULP 

ENVIRONMENT . ) 

Invoking Foreign Programs 

There are two broad contexts in which it is desirable to cruse a 
specific local program to be invoked from the common commrnd 
environment: The User side of the connection may itself be a program* 

RND THE DESIRED SERVER SIDE PROGRRM R SPECIFICALLY COOPERATING ONE* THIS 
IS THE MORE SOPHISTICRTED CONTEXT* OF COURSE. THE LESS SOPH IST ICRTED 
CONTEXT RSSUMES THRT THE USER SIDE IS R "LIVE" USER? RND THE DESIRE IS 
TO INVOKE R COMPILER DR RN OBJECT PROGRRM THE USER HRS RLRERDY COMPILED 

IN THE COMMON LANGUAGE - RGRIN RS R CONVENIENCE TO THE USER SO THRT HE 

MRY OPERATE IN R SORT OF "SERVER—TRANSPARENT" MODE. (The LATTER CASE 
ALSO COVERS "BATCH" USE OF THE SERVER* SEE BELOW.) In BOTH CONTEXTS* THE 
IMPORTANT ROLE. OP THE UULP IS TO SPECIFY THE MECHANISMS THROUGH WHICH 
THE PARTICULAR PROGRAMS MRY BE INVOKED* IRRESPECTIVE OP THE 
IDIOSYNCRASIES OP THE SERVERS' - COMMRND LANGUAGES. 

Programming languages are much too big r problem to tackle here. 
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However? assuming thrt a user -somehow manages to create a source 

PROGRRM? HE STILL WRNTS SOME CQMMONRLITY OF SPELLING IN INVOKING THE 
APPROPRIATE COMPILER? OR EVEN THE OBJECT PROGRRM. fls AN OPTIONRL BUT 
STRONGLY RECOMMENDED UULP COMMRND ? THEN? "CALL NAME" SHOULD INVOKE 
OBJECT PROGRRM NAME (WHERE THE NAMED PROGRAM MAY BE A “NATIVE" COMMAND 
WITH AGRUMENTS SPECIFIED AS APPROPRIATE) . THE VALUES “-PLl" ? "“BASIC"? 
"“FORTRAN"? "“LISP"? ETC.? SHOULD EE RECOGNIZED AS REGUESTING THE 
INVOCATION OF THE APPROPRIATE LANGUAGE PROCESSOR (TO OPERATE ON A NAMED 
SOURCE FILE OR INTERPRETIVELY/INTERACTIVELY IF NO SOURCE FILE WAS 
NAMED)> WITH "REASONABLE" DEFAULTS IN EFFECT. HqTE THAT THIS ALL IS 
MEANT TO IMPLY THAT "NATIVE" COMMANDS ARE NOT DIRECTLY INVOKABLE FROM 
THE UULP ENVIRONMENT (OTHER THAN BY "CALL")? TO AVOID POTENTIAL NAMING 
CONFLICTS BETWEEN SYSTEM COMMANDS AND NEW UULP COMMANDS. 

Note that the "call" command in the UULP environment constitues a 

RUBRIC FOR "PARALLEL" COMPUTATION? GIVEN ANY AD HOC CONVENTION FOR 
THE RETURN OF COMPLETION INFORMATION. (WRITING ON THE TELNET WRITE 
SOCKET PLUS £ WOULD SEEM APPROPRIATE? PROVIDED THE INITIATOR HAS THE 
ABILITY TO "LISTEN" FOR THE RFC? BUT EVEN A RESPONSE IN THE DATA 
STREAM WOULD DO? AS A SPECIAL“CASED PROGRAM IS ASSUMED ON THE "USER“ 
SIDE ANYWAY.) 

□ther Matters 

The topic of "batch" mode merits some attention, fls with the file 

MANIPULATION COMMANDS? MORE CONSULTATION IS NECESSARY FOR A FIRM SPEC. 

However? I suspect that a "-batch" control argument to login should 

INITIATE BATCH MODE PROCESSING BY THE SERVER? AND GIVEN THE CALL AND 
IDENTIFY COMMANDS ALL WE MIGHT THEN REEUIRE IS A CONVENTION FOR 
DESIGNATING THE OUTPUT FILE IN ORDER TO RETURN IT VIA A COPY COMMAND IN 
THE "JOB" ITSELF (IF OUTPUT IS TO BE RETURNED RATHER THAN STORED AT THE 

Server) . Df course ? -batch will probably need some substructure as to 

PASSWORD AND TIMING MATTERS. MORE DETAILS WILL EMERGE IN THIS AREA IN 
FUTURE ITERATIONS. 

flN ADMITTEDLY FICTIONALIZED SCENARIO MIGHT LOOK LIKE THIS! 

LOGIN Me -batch -pw XXX “SHIFT 3 
COPY ♦452<ME>SOURCE .TEXT SOURCE.pl2 
CALL -PL2 SOURCE 
CALL SOURCE INPUT OUTPUT 
IDENTIFY Me2 YYY 

copy output ♦555>rdot>Me>output452 

LOGOUT 

WHERE USER "Me" WANTS THE SERVER RECEIVING THE COMMANDS (EITHER DIRECTLY 
FRM HIM AT A TIP OR PERHAPS FROM SOME OTHER SERVER ON WHICH HE HAS 
CREATED A FILE CONTAINING THEM) TO SET UP A BATCH JOB FOR HIM? WITH 
PASSWORD "XXX"? TO BE RUN ON SHIFT 3 (WHENEVER THAT IS). THE JOB FIRST 
COPIES FILE “SOURCE .TEXT" FROM DIRECTORY “<ME>“ ON HOST 452 INTO LOCAL 
FILE "SOURCE .PL2" ? THN COMPILES IT WITH THE LOCAL PL2 COMPILER? EXECUTES 
it (assuming a "Mot found" response would go into a known file if 

COMPILATION HAD FAILED) WITH APECIFIED ARGUMENTS (PRESUMABLY THE NAMES 
OF FILES FOR INPUT AND OUTPUT)? THEN COPIES THE "OUTPUT" FILE TO HOST 
555'S FILE HIERARCHY AT THE INDICATED PLACE? USING THE USER IDENTIFIER 
"Me2“ and the password "yyy". It's not elegant? but it ought to work. 
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Finally? on the topic of logging out? the UULP commrnp is "logout". The 
Server must close the Telnet connection rfter doing whatever is 

APPROPRIATE TO EFFECT A LOGOUT. To RETAIN THE TELNET CONNECTION? "LOGOUT 

-save". Having the Server close is viewed as a convenience for the user? 

IN THAT IT SPARES HIM THE NECESSITY OF CAUSING HIS USER TELNET TO CLOSE. 

It is also desirable for program-driven applications? so as not to leave 

THE CONNECTIONS "DANGLING" AND NOT TO REEUIRE POSSIBLY COMPLEX 
NEGOTIATIONS WITH THE USER SIDE TO BREAK THE CONNECTION. 

APPENDIX 1 . THE COMMON COMMAND SUBSET 

Syntax Opt 


I. "Set-up" Commands 

LOGIN ID RRG 

The id may be Network-wide or Host-specific. 

"♦free" is reserved. 

The arg may be "-mail"? “-who"? "-concdm"? 

"-batch"? or may be absent. 

Result is to be either logged in dr passed off to appropriate daemon. 

PROMPT CHAR 

Specifies that char is to become or 

PRECEDE THE NORMAL PROMPT MESSAGE. 

Acceptable prior to login. 

ERASE CHAR 

Specifies that char is the erase character. 

Invocation with, no argument reverts to default. 

KILL CHAR 

Specifies that char is the kill character. 

Invocation with no argument reverts to default. 

EQL CHAR 

Specifies that char is the newline character. 

Invocation with no argument reverts to default. 

local 

Enter the local command environment. 

FTP 

Enter the FTP environment. 

RJE 

Enter the RJE environment, 
logout 

Logout and sever the Telnet connection. 

# ' 

LOGOUT -SAVE 

Logout but keep the Telnet connection. 
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MAP 

HPPLY THE CASE~MAPPING CONTENTIONS OF APPENDIX 2. 

Required on Hosts to which case is significant. 


IDENTIFY ID ARC X 

Specifies that id is to se used as the user 

IDENTIFIER IN ANY "FANOUT" LOGINS REQUIRED. 

If ARG IS SPECIFIED? IT IS TO EE EITHER THE 
PASSWORD TO BE USED IN SUCH LOGINS OR "-PW"? IN 

WHICH CASE THE SERTER WILL FURNISH A MASK OR NEGOTIATE THE HlDE YOUR 

Input Telnet option? if no arg ? then no password is to be furnished on 

FANOUT LOGINS. 

Default id is "♦free“S 


II. Communications Commands 


READMAIL 

Type out "mailbox". 

READMAIL (ib) “AT HOST X 

Type out "mailbox" on remote Host host. 

Multiple Hosts may be specified? 

SEPARATED BY SPACES (BLANKS). 

Implies ability to change working directory 

AT HOST TO DIRECTORY IMPLIED BY KNOWN 
USER IDENTIFIER? OR (OPTIONALLY) BY ID. 

READMAIL “ALL XX 

Search for mail. 

Extremely optional. 


MAIL ID 

Collect input until line consisting of ’W- 

ONLY A PERIOD FOR MAILING TO LOCAL 

USER SPECIFIED BY ID. 


MAIL -F FILE ID 

Send contents of specified file to specified 

LOCAL USER. 


MAIL ID -AT HOST 

Collect input until line consisting 

ONLY A PERIOD FDR MAILING TO 

USER(S) AT SPECIFIED HoST(s). BOTH 
HOST MAY BE MULTIPLE? SEPARATED BY 

(.If multiple? they should be taken 


OF 

REMOTE 
ID AND 
SPACES. 
PAIRWISE 




MAIL ~F FILE ID “AT HOST 

Send contents of specified file to specified 

REMOTE USER(S) . 


WHO 

The generic who'‘s logged in command 
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WHO ID 

Is ID COGGED IN? CONSTRAINED RESPONSES. 

WHO ID -AT HOST 

IS THE SPECIFIED USER COGGED IN AT THE 
SPECIFIED HOST. CONSTRAINED RESPONSES. 

CONCOM -ON 

Enabce consoce to consoce communications. 

CONCOM “OFF 

BlSABCE CONSOCE TO CONSOCE COMMUNICATIONS. 

CONCOM ID 

Send messages to specified cocac user 

UNTIC CINE CONSISTING OF ONCY A PERIOD 
CONCOM ID -AT HOST 

Send messages to specified remote user. 

III. Fice Commands 

TYPE PATH 

Type out the contents of the specified fice. 

Pathname may be cocac or Network—wide• 

Defauct to current working directory. 

Cl STDIR 

List the contents of the current working directory. <Locac format 

AC CEPTABCE . > 

CISTDIR PATH 

List the contents of the specified directory. 

RENAME OCD NEW • " 

Change the specified fice's name as indicated. 

ADDNAME OCD NEW . 

Gii^E the specified fice the specified extra name. 

DECETE PATH 

Get RID OF THE SPECIFIED fice. 

<"Expunge" if necessary.> 

COPY FROM TO . 

Make a copy of the fice specified by the first pathname at the second 

PATHNAME . 

CINK FROM TO 'X 

If YOUR FICE SYSTEM HAS SUCH A CONCEPT » MAKE A "CINK" BETWEEN THE TWO 
PATHNAMES. If NO SECOND ARGUMENT» 

USE SAME ENTRY NAME IN WORKING DIRECTORY. 


P 


X 


STATUS PATH ST 


X 
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If your file system has such a concept i give status information about 

THE SPECIFIED FILE DR DIRECTORY. 

CHANSEWD PATH X 

If no arsument j return to the "home" directory. 

TYPEWD X 

Type out the pathname of the current working directory. 

NETED PATH X 

See Appendix 3. 

IV. Invoking "Native" Programs 

CALL NAME <ARGS) X 

Invoke the specified program with the 

SPECIFIED ARGUMENTS (IF ANY). 

The FOLLOWING NAMES ARE RESERVED TO INDICATE THE 

INVOCATION OF THE CORRESPONDING LANGUAGE PROCESSOR! "“PL 1“ > “"BASIC" > 
""FORTRAN" ! "-lisp". 

<If NO SOURCE FILE INDICATED* INVOKE INTERPRETIVELY" IF POSSIBLE.) 

V. On-line Documentation 
* 

HELP NAME 

Type out information about the specified UULP command. If name is 

"-SYS"? TYPE OUT INFORMATION ABOUT HOW TO USE THE LOCAL SYSTEM'S HELP 
ME CHAN ISM* IF 

"—UULP"* ABOUT THE LOCAL SYSTEM'S UULP IMPLEMENTATION. If NO NAME GIVEN* 
DESCRIBE THE COMMAND ITSELF. 

APPENDIX 2. MAP COMMAND CONVENTIONS 

This appendix will eventually contain the case-mapping conventions 
DETAILED IN RFC 411. 

APPENDIX 3. EDIT COMMAND REQUESTS 

This appendix will eventually contain descriptions of the neted command 

REQUESTS (ft DRAFT OF WHICH NOW EXSITS) > OR ft REFERENCE TO THE RESOURCE 

Notebook version* if that gets published first. For now? it should be 

SUFFICIENT TO POINT OUT THftT THE REQUESTS ARE BASICALLY LOCATE? NEXT* 

TOP? CHANGE* SAVE * AND QUIT - I.E.* IT'S THE "OLD-FASHIONED" FLAVOR OF 

CONTEXT EDITOR. 




